Described below is a method and system for continuously transmitting encrypted data of a broadcast service to a mobile terminal that changes over from a service access network having a first key hierarchy to another service access network having a second key hierarchy.
With point-to-multipoint data services, multimedia data in particular such as, for instance, audio and video data is transmitted to a terminal by a content or service provider's server. If the terminal is a mobile terminal or user terminal BEG such as, for example, a mobile telephone or laptop the data will be transmitted by the service provider's server via a service access network DZN and from there to the mobile terminal over a radio interface. Various multicast or access technologies are known that each employ different procedures for authenticating and registering users, thereby controlling access to the multicast or broadcast services. Examples of the kind of known broadcast technologies are the Multimedia Broadcast and Multicast System (MBMS) specified in the 3GPP (Third Generation Partnership Project), the DVB-H (Digital Video Broadcast to Handhelds) system based on the IP Internet Protocol and abbreviated to DVB-H IPDC (DC: Data Cast), the 3GPP2 BCMCS (Third Generation Partnership Project 2 Broadcast Multicast Service) system, and the OMA BCAST (Browser and Content Broadcast) of the standardizing body of the Open Mobile Alliance (OMA). The different access technologies for provisioning broadcast or multicast services for mobile terminals employ in particular different key hierarchies for encrypting data transmission links.
The different service access networks have partially overlapping coverage areas so that a mobile terminal can move from a first service access network's coverage or transmission area to a transmission area of a second service access network having a different access technology. Mobile terminals or user terminals BEG are able to support different access technologies for receiving the corresponding broadcast services.
The Multimedia Broadcast Multicast System (MBMS) specified by the Third Generation Partnership Project (3GPP) standardizing body implements IP-based point-to-multipoint data services in 3GPP mobile radio networks (3GPP MBMS ARC). Examples of data services of the type are audio, video and voice services (streaming services), but also services with the aid of which images and texts are beamed to terminals (downloading and what are termed carousel services). Alongside the Radio Access Network (RAN) and Serving and Gateway GPRS Support Nodes (SGSN and GGSN), the user terminal (User Equipment—UE) and the Broadcast Multicast Service Center (BM-SC) are the most important MBMS network components. The actual data content is made available to the BM-SC by a Content Provider (ContProv).
MBMS streaming services in the case of which unauthorized use is to be prevented can be encrypted with the aid of the Secure Realtime Transport Protocol (SRTP) and protected against being changed (integrity protection). That function is assumed by the BM-SC (3GPP MBMS SEC). Cryptographic key material must be made available for that purpose at the BM-SC and at the appropriately authorized user terminals (UE). For reasons of efficiency a specific MBMS streaming service cannot be separately protected and radiated for each individual terminal; rather it is the case that the BM-SC and authorized terminals share what are termed MBMS traffic keys (MTK). Although changing frequently, MTKs are not specific to a particular terminal.
MTKs are encrypted with the aid of what are termed MBMS Service Keys (MSK) so that they cannot themselves be intercepted on their way from the BM-SC to the mobile terminals BEG. MSKs are much longer-lived than MTKs and so have to be transmitted less frequently to the UEs than MTKs. MSKs must of course also be protected from interception while being transported to the BEGs. That is achieved with the aid of what are termed MBMS user keys (MUK). In contrast to MTKs and MSKs, an individual MUK is valid only for a single terminal BEG. That also means that an MSK that is radiated encrypted by a specific MUK can be decrypted only by the terminal BEG that knows the MUK.
MUKs are negotiated between the terminal BEG and BM-SC with the aid of what is termed the Generic Bootstrapping Architecture (GBA). The GBA is a method specified by the 3GPP for deriving a security relationship between the terminal BEG and what is termed a Network Application Function (NAF) from the security relationship existing in any event between the terminal BEG and mobile radio network (3GPP GBA). In association with the MBMS the BM-SC assumes the role of the NAF.
Independently of the MBMS, the terminal BEG and a Home Subscriber Server (HSS) in the BEG's home network share a long-lived, secret key K stored on the BEG's Universal Integrated Circuit Card (UICC) and in a database of the HSS server. The terminal BEG and the GBA component responsible therefor having the name Bootstrapping Server Function (BSF) mutually authenticate themselves on the basis of the key K. The HSS server therein supplies the BSF with the relevant, in part terminal-specific data (Zh, reference point). In association with the authenticating the terminal BEG and the BSF derive a secret key Ks serving to generate a key Ks_NAF that depends on the identity of the NAF. The bootstrapping server BSF informs the NAF (the BM-SC in the MBMS example) of the Ks_NAF (Zn reference point) on request so that the terminal and NAF will then share a secret cryptographic key, namely the Ks_NAF. Thus a security relationship will be established overall between the terminal UE or BEG and the NAF (key Ks_NAF) based on the existing security relationship between the terminal and mobile radio network (key K).
In the case of the MBMS the terminal and BM-SC derive from the Ks_NAF what is termed an MBMS Request Key (MRK) with the aid of which the terminal authenticates itself to the BM-SC (Ua reference point). The UE will thereby obtain the authorization to receive a specific MBMS service. The authorization causes the BM-SC to send the terminal an MBMS Service Key (MSK) encrypted with the aid of an MBMS User Key (MUK) derived from the MRK. As already mentioned above, only the terminal having the MUK derived from the MRK will then be able to decrypt the MSK. However, with the aid of the MSK the terminal will be able to decrypt the non-terminal-specific MBMS Traffic Keys (MTK) and hence the entire, SRTP-protected MBMS streaming service and check the data's integrity. The security of the 3GPP MBMS is thus based on the following key hierarchy:
Long-lived 3GPP key K                known only to the BEG and an HSS in the BEG's or UE's home network        serves in the case of the GBA for authenticating between the BEG and BSF GBA keys Ks and Ks_NAF        Ks is derived in association with the GBA authentication procedure between the BEG and the BEG's home network and serves to generate the key Ks_NAF        the keys MRK and MUK are in the case of the MBMS derived from the Ks_NAF        
MBMS Request Key (MRK)                derived by the BEG and BM-SC from the Ks_NAF        serves to authenticate the BEG to the NAF=BM-SC and authorize it there during service registering        
MBMS User Key (MUK)                derived from the Ks_NAF        serves to perform BEG-specific encrypting of the MSK        
MBMS Service Key (MSK)                generated by the BM-SC for a specific service        serves to encrypt MTKs during transportation to the BEGs        is valid longer than MTKs        
MBMS Traffic Keys (MTK)                keys generated by the BM-SC for protecting (encryption and integrity protection) an MBMS service        not BEG-specific        are transmitted to BEGs encrypted with the aid of the MSK        
The Digital Video Broadcast (DVB) standardizing body has published specifications that define video broadcast services to mobile terminals BEG (DVB to handhelds—DVB-H) based on the Internet Protocol (IP): IP Data Cast over DVB-H, abbreviated to IPDC/DVB-H (DVB IPDC). The DVB-H system therein does not just have a unidirectional broadcast channel but also an optional bidirectional interactive channel that can be realized by, for example, a 3GPP mobile radio network.
The DVB-H document “IP Data Cast over DVB-H: Service Purchase and Protection” (DVB IPDC SPP) specifies two different security systems for DVB-H services:
System 1: Open Security Framework (OSF)                recommends the encrypting of broadcast services at the data content level (ISMACryp)        
System 2: 18Crypt                recommends the encrypting of broadcast services at the transport level (SRTP) or network level (IPSec)        
User terminals BEG corresponding to the SPP specification must support all three encryption methods (ISMACryp, SRTP, IPSec) and implement at least one of the two systems.
FIG. 1 shows a DVB-H model for protecting data content in the case of broadcast services according to the related art.
The terminal BEG (Device) initially requires a long-lived key K that is unambiguous for that device. A key of the type will as a rule already be located on the device when purchased or else on a chip card that is inserted into the device. The key forms the basis of the security of the four layers, which are shown in FIG. 1.
At the topmost layer (Registration) the terminal (Device) authenticates itself with the aid of an unambiguous key K and registers for a specific broadcast service. On the basis of successful authenticating and registering the terminal obtains a cryptographic key (Rights Encryption Key) necessary for receiving the service. The Rights Encryption Key is encrypted with the aid of the device-specific key K so that only the terminal that has the key K will be able to decrypt the Rights Encryption Key.
At the second layer (Rights Management) the terminal obtains a Service Encryption Key (SEK) that is valid for longer and is transmitted to the terminal with the aid of a Key Management Message (KMM). The SEK is unambiguous for the broadcast service but not for the terminal. The Rights Encryption Key serves to encrypt the SEK. The SEK is comparable in terms of its functionality to the 3GPP-MBMS Service Key (MSK).
At the third layer (Key Stream) what are termed Key Stream Messages (KSM) transport short-lived Traffic Encryption Keys (TEK) to the terminals via the broadcast channel. The TEKs are therein encrypted by the Service Encryption Key (SEK) previously transmitted at the second layer. At the bottommost layer (Content/Service Protection) the broadcast service—encrypted with the aid of the TEKs—is radiated via the broadcast channel.
With the aid of its device-specific key K the terminal is able to decrypt the Rights Encryption Key and hence in turn the SEK and then the frequently changing TEKs. The registered and consequently authorized terminal BEG will hence be able to display the encrypted broadcast service in plain-text form.
The model shown in FIG. 1 describes the technical realization of the protective measures of IPDC/DVB-H at a very general level. That is because, on the one hand, the model indicated in [DVB IPDC SPP] represents the two, very different systems “Open Security Framework” and “18Crypt” in a uniform manner and, on the other hand, the technical realization of layers 1-3 (Registration, Rights Management, and Key Stream) is not explicitly specified in [DVB IPDC SPP] for the Open Security Framework system but instead left open—in contrast to the 18Crypt system, for which all layers have been defined.
The 18Crypt system is based on Digital Rights Management (DRM) methods defined by the Open Mobile Alliance (OMA) [OMA DRM]. As the unambiguous device key it uses a public encryption key whose link to a specific device is authenticated by a digital certificate. What is termed a Rights Issuer (RI) checks the digital device certificate's validity for authenticating and registering the device at the Registration layer. If the check is successful the RI will send the device what is termed a Rights Object (RO) at the Rights Management layer. The RO contains a Service or Program Encryption Key (SEK/PEK) that has been encrypted with the aid of the checked, public device key. Only the device specified in the digital certificate has the corresponding private device key. It will hence be the only device that can decrypt the encrypted SEK or PEK in that Rights Object RO.
Alongside the SEK or PEK the Rights Object RO as a rule also contains the description of rights granted to the device in terms of the data content of the broadcast service for which the device has registered (for example: Video is allowed to be played by the terminal five times). A change-protected program (DRM Agent) on the terminal is responsible for decrypting the SEK or PEK, for adhering to the rights granted to the device in terms of specific data content, and for protecting the SEK or PEK against unauthorized access. The SEK or PEK is used at the Key Stream layer for encrypting and decrypting frequently changing Traffic Encryption Keys (TEK).
IP-based broadcast and multicast services are realized with the aid of the Broadcast Multicast Service (BCMCS) in mobile radio networks conforming to the standards of the Third Generation Partnership Project 2 (3GPP2) [3GPP2 BCMCS]. 3GPP2 user terminals (Mobile Station—MS) have a User Identity Module (UIM) and the actual mobile device (Mobile Equipment—ME). A UIM can be either permanently linked to the ME or removable (Removable UIM-R-UIM). Whereas UIMs have a protected memory area but only little computing power, the mobile device ME has more computing power but no protected memory area.
The Secure Real-time Transport Protocol (SRTP) can be used for encrypting the broadcast/multicast data content. The keys serving as the input for SRTP encrypting are called Short-term Keys (SK). Like 3GPP MBMS Traffic Keys (MTK) they change frequently but are not, like MTKs, sent encrypted to the mobile stations MS. An encrypted Broadcast Access Key (BAK) is instead sent to the mobile terminals or MSs together with a random number SK_RAND and the mobile terminals BEG or MS compute the key SK from the BAK and SK_RAND. The BAK is not an MS-specific or UIM-specific key; rather it is the case that the BAK is valid for one or more IP multicast message flows. The BAKs are generated by the network component BAK Distributor (BAKD).
A BAK is encrypted on its way to a mobile terminal BEG or MS with the aid of a Temporary Encryption Key (TK). Each TK depends on a random number TK_RAND and on what is termed a Registration Key (RK). The RK is therein unambiguous for each UIM and known only to the relevant UIM and the network component responsible for generating TKs (Subscription Manager—SM). Along with the BAK encrypted by the TK, the mobile terminal also receives the random value TK_RAND. Only the mobile terminal having on its UIM the RK that was used for generating the TK will then be able to derive the key TK with the aid of TK_RAND. The TK is used by the mobile terminal to decrypt the BAK. The MS or BEG will then be able to compute the SK with the aid of the BAK and SK_RAND and hence decrypt the encrypted multicast data.
3GPP2 BC MCS's security is based on the following key hierarchy:
Registration Key (RK)                unambiguous for each UIM        known only to the UIM and Subscription Manager (SM)        
Temporary Encryption Key (TK)                derived from the RK and a random number TK_RAND        serves to encrypt a Broadcast Access Key (BAK)        the MS receives the TK_RAND together with the encrypted BAK        only the MS having the correct RK is able to compute the TK with the aid of the TK_RAND        
Broadcast Access Key (BAK)                generated by the BAK Distributor (BAKD) for one or more IP multicast message flows        the MS receives the BAK encrypted by the TK along with a random number SK_RAND        
Short-term Keys (SK)                keys for encrypting (SRTP) broadcast/multicast data        not sent to the MS but computed by the MS from the BAK and SK_RAND        
The Broadcast (BCAST) Sub-Working Group of the Browser and Content (BAC) Working Group of the Open Mobile Alliance (OMA) standardizing body is standardizing what is termed an Enabler for Mobile Broadcast Services that are offered over networks having a unidirectional broadcast channel (for example DVB-H) and an optional, bidirectional unicast channel (for example 3GPP) [OMA BCAST ARC]. What is being specified therein are functions such as Service Guide, File Distribution, Stream Distribution, Service Protection, Content Protection, Service Interaction, Service Provisioning, Terminal Provisioning, and Notification.
In the current draft specifications, OMA BAC BCAST supports in particular 3GPP MBMS, DVB-H IPDC, and 3GPP2 BCMCS as broadcast distribution systems. The protection of broadcast services (Services) and content (Content) has been defined in [OMA BCAST SCP] and is offered in three variants: A DRM profile that is based on the OMA specifications for Digital Rights Management [OMA DRM] and two smartcard profiles based respectively on 3GPP (U)SIM and 3GPP2 (R)UIM.
Owing to the different access technologies and in particular to the different key hierarchies employed for the various access technologies, the problem of interrupted data transmission arises when a mobile terminal BEG changes over from a first service access network to a second service access network.
Changeover from one service access network to another service access network can take place owing either to a mobile terminal's moving out of a first service access network's transmission area into a second service access network's transmission area or to the user's wishing to change over from a first service access network to another service access network.